ZTA Supported Features
•Enrolling for nZTA Connections
•Authentication Methods and Policies
•Host Checker OS Version Support
•Dynamic Policy Update and CARTA
•Split Tunneling (IPv4 FQDN based app access)
•Minimum Client Version Enforcement
Introduction
The Ivanti Secure Access Client is a ZTA-ready software solution that is required for end-user devices to be able to connect to your secure applications and resources.
Ivanti Secure Access Client connects to ZTA services, by default, through an on-demand connection basis and can handle multiple simultaneous ZTA and non-ZTA connections. To learn more, see On-Demand and Simultaneous Connection Handling.
To learn more about enrolling user devices for use with ZTA, see Enrolling a User Device.
Enrolling for nZTA Connections
On installing Ivanti Secure Access Client, the user can configure an nZTA connection using the same process used for other, existing connections (VPN Connections). To create an nZTA connection, compatible Ivanti Secure Access Client versions offer a specific connection type: “Zero Trust Access”.
The tenant administrator must supply the nZTA enrollment URL to their users to create the new nZTA connection.
For Mobile Application users, when using default enrolment URL, ensure you omit “/login/enrol” at the end of the URL.
Adding a Connection
To add a new nZTA connection:
1.Click 
. Enter the enrollment URL. The Add Connection dialog box opens.
2.Enter the enrollment URL and click Submit.
3.The network type auto populates as Zero Trust Access.
4.For Name, specify a descriptive name for this connection. The name you specify appears in the Ivanti Secure Access Client interface.
5.For Server URL, enter the nZTA controller URL as provided by the administrator.
6.Click Add to save your new connection and the connection displays in the Home page.
7.Click Enroll to initiate the enrollment to nZTA.
8.On Home page, swipe the connection to Enroll and initiate a connection to the network. Enter the credentials to complete the connection.
Deleting a Connection
To delete an nZTA connection:
1.Click the connection to select it.
2.Click vertical three dots (
), and then select Delete.
3.Confirm to the prompt to delete the connection.
Enrolling First Time Users
When enrolling a new device, an authorized user contacts the ZTA Controller to activate an initial first-time enrollment of their client device.
After Ivanti Secure Access Client is installed, a secure connection request is attempted with the Controller. The request is validated against the designated authentication policy applicable to that combination of user and device and, where successful, a connection profile is downloaded to the client. This profile enables Ivanti Secure Access Client to set up a secure tunnel directly to the ZTA Gateway serving the resource set the client is authorized to view.
Enrolling Existing Users
After you have enrolled the new device, Ivanti Secure Access Client is installed and configured with the policies and settings relevant to the device type. Your application and resource access rights should be duplicated to the new device.
If a user device is currently using a Beta version of the ZTA-ready Ivanti Secure Access Client, Ivanti advises to remove the ZTA connection from Ivanti Secure Access Client and to re-perform the enrollment procedure through a web browser. For more details, see your support representative.
Host Checker OS Version Support
The device rule checks if the client device’s Operating System meets a defined minimum standard. For details, see Options for OS Rules.
Authentication Methods and Policies
You can create authentication methods and apply them to the authentication policies you define in your Ivanti Neurons for Zero Trust Access (nZTA) deployment. You then apply an authentication policy, together with user rules, to a user group. A user group forms part of a Secure Access Policy.
nZTA supports the following types of authentication methods:
•Local authentication: An authentication system that is internal to the Controller. You must create all users manually on the Controller, and update any required authentication policies. If you are configuring Multi-Factor Authentication (MFA) in your deployment, you can configure local user authentication as either the primary or secondary authentication method.
•Azure AD SAML authentication: An existing remote SAML authentication system based on an Azure AD server.
•On-prem ICS SAML authentication: An existing remote SAML authentication system based on an on-premises ICS server.
•Okta SAML authentication: An existing remote SAML authentication system based on Okta.
•PingID SAML authentication: An existing remote SAML authentication system based on PingID.
•TOTP authentication: Time-based One Time Password (TOTP) authentication as a secondary mechanism in Multi-Factor Authentication deployments.
For details, see Working with User Authentication.
Dynamic Policy Update and CARTA
Ivanti Secure Access Client maintains communication with the Controller to continuously-enable synchronization of policy and configuration updates. Through this mechanism, user requests to access resources and applications are subject to continuous assessment for risk and authorization. For details, see Dynamic Policy Update and CARTA.
Transition from Classic to nZTA
This feature provides seamless experience to Classic VPN user, where user can perform effortless transition from their classic connection to On-demand nZTA connection. When classic connection is active, client keeps monitoring the accessed resources. Whenever client finds that the user has accessed the ZTA resource, it triggers the disconnect from classic profile and triggers On-Demand nZTA connection.
Split Tunneling (IPv4 FQDN based app access)
A secure access policy defines how end-users can connect to Ivanti Neurons for Zero Trust Access (nZTA) to access applications. Each secure access policy is defined in terms of four dimensions: Gateways, Users, Devices, and Applications.
FQDN-Based Split Tunneling supports up to 2048 FQDN entries.
Configuring FQDN based Split tunnel policies is supported for Android clients. For reference and further updates, please see KB44502. For best results, keep split tunneling configuration within the supported thresholds.
For details, see Creating/Editing Secure Access Policies.
Integrating NMDM with nZTA
This feature supports the compliance check for mobile devices during log-in and application access. For details, see Integrating Ivanti Neurons for MDM with nZTA.
Minimum Client Version Enforcement
This feature provides an option for the admin to force upgrade the client version when Minimum Client Version is configured. For details, see Enabling Minimum Supported Client Version.